I will also disable Qt6 to not spend too much time on build system changes during the reorganisation and iOS+Windows CI temporarily as they are slow.

@ntadej Thank you very much for your work! I am super happy that this wonderful project makes the step toward Qt6.5.

Ping @louwers again 😊

Using QtCreator + Qt 6.5.0 on Windows give the following error:

  get_target_property() called with non-existent target
  "Qt6::QGeoServiceProviderFactoryMapLibreGLPlugin".
Call Stack (most recent call first):
  CMakeLists.txt:38 (qt_internal_add_plugin)

Perhaps somebody knows already what is wrong and saves me a lot of time? :)

There's a Qt bug where they hardcode some things in their internal CMake. My goal is to try to move away from internal Qt CMake functions, but it will make the library slightly harder to either develop or use 😊

I don't have my installation at hand, but the function is called something like "qt target aliases", where they hardcode Qt6 somewhere, which should be changed to something like Qt${PROJECT_VERSION_MAJOR}.

Hmmm.... but in my case, it shouldn't matter. I use Qt 6 :)

And besides that, it doesn't seem to be hard-coded. At least not anymore:

# Add Qt::target and Qt6::target as aliases for the target
function(qt_internal_add_target_aliases target)
    set(versionless_alias "Qt::${target}")
    set(versionfull_alias "Qt${PROJECT_VERSION_MAJOR}::${target}")
    set_target_properties("${target}" PROPERTIES _qt_versionless_alias "${versionless_alias}")
    set_target_properties("${target}" PROPERTIES _qt_versionfull_alias "${versionfull_alias}")

    get_target_property(type "${target}" TYPE)
    if (type STREQUAL EXECUTABLE)
        add_executable("${versionless_alias}" ALIAS "${target}")
        add_executable("${versionfull_alias}" ALIAS "${target}")
    else()
        add_library("${versionless_alias}" ALIAS "${target}")
        add_library("${versionfull_alias}" ALIAS "${target}")
    endif()
endfunction()

I remember now, PROJECT_VERSION_MAJOR is the version of the project that uses it (which is not 6 in our case). They also have something like QT_VERSION_MAJOR that they use elsewhere.

A, yes, of course! Didn't spot that. Using QT_VERSION_MAJOR doesn't work because it's evaluated only when using find_package(QT NAMES Qt6 Qt5 and not find_package(Qt6. Just hard-coded with 6 right now.

My idea is to have a consistent API between Qt5 and Qt6 (as much as Qt allows). My app is still Qt5 on some platforms (Windows for example).